The invention relates generally to processing techniques for object-oriented software applications and, more particularly, to object-oriented software applications which utilize quasi-singleton objects during the execution thereof.
Modern telecommunication switches contain vast amounts of software. Much of it is included in the switch""s CP subsystem which provides both basic call service as well as advanced features such as call forwarding, call waiting and conference calling. As the CP subsystem of a switch must be continuously available, able to process millions of transactions per hour and maintain a software error rate of 0.0001% of all calls handled thereby, configuration of the CP subsystem is oftentimes of foremost concern.
Many of the software applications which reside on a switch and form part of the CP subsystem are object-oriented in that, to execute the application, one or more objects are used by the application. An xe2x80x9cobjectxe2x80x9d is a discrete combination of code, i.e., a sequence of computer instructions, and data, i.e., information which the instructions operates on, maintained by the CP subsystem. Objects used by applications of the CP subsystem may be static or dynamic. Static objects are neither created nor destroyed because they persist across calls. For example, an object which contains a finite state machine""s (xe2x80x9cFSM""sxe2x80x9d) static mappings from state-event pairs to event handlers is a static object. Other static objects are created dynamically by other subsystems but are viewed as static by the CP subsystem. For example, a trunk group manager is created when a trunk group is defined using the switch""s provisioning subsystem, and a trunk group member is created when a channel on a carrier is assigned to a trunk group. Dynamic objects are typically created on a per-call basis. As a result, therefore, in most object-oriented systems, memory for dynamic objects must be allocated and deallocated as the dynamic objects are created and destroyed.
Pooling is used to minimize the time spent allocating and deallocating memory for dynamic objects. Memory comprised of a selected number of object data blocks (xe2x80x9cODBsxe2x80x9d) is allocated for objects when the system is initialized. The ODBs are placed in pools based upon object types. For example, a CP subsystem may include eight dynamic object poolsxe2x80x94message, acceptor, active feature element (xe2x80x9cAFExe2x80x9d), logical signaling channel (xe2x80x9cLSCxe2x80x9d), event, logical bearer channel (xe2x80x9cLBCxe2x80x9d) and physical bearer channel (xe2x80x9cPBCxe2x80x9d). Dynamic objects may then be created using ODBs removed or xe2x80x9cdequeuedxe2x80x9d from the ODB pool.
As should be readily appreciated, both the creation of a dynamic object, as well as its destruction, consumes time. As a result therefor, performance of a CP subsystem can be adversely affected, particularly if the one or more dynamic objects to be used thereby must be repeatedly created and destroyed. For example, if a dynamic object is created each time a request for connection is received and then destroyed when the connection is completed, a CP subsystem will have created and destroyed the same object thousands of times in a matter of minutes. While the aforementioned use of ODB pools avoid the repeated creation and destruction of dynamic objects, using ODB pools still involves a repetitive processxe2x80x94the continual dequeuing and requeuing of ODBs in the ODB pool. If such repetitive processes could be avoided, performance of the CP subsystem, as well as other object-oriented software systems, could be enhanced.
In one embodiment, the invention is of a method of executing a software application by first determining if execution of the software application raises an event handled by a single use dynamic object. If so, the single use dynamic object is implemented as a quasi-singleton suitable for re-use in multiple executions of the software application. During first (and next) executions of the software application, the quasi-singleton is used (and re-used) to handle the event. By implementing single use dynamic objects as quasi-singletons cached in storage, considerable processing time consumed by the repeated dequeuing and enqueuing of a dynamic object in an ODB pool is saved.
While suitable for any application, preferably, the software performs a call processing application and is incorporated in a mobile switching center or other telecommunications switch. Call processing applications are preferred since they: (1) typically raise a series of events which must be handled in sequence; and (2) are executed repeatedly. Thus, when a request for executing the application is received, it is unlikely that the quasi-singleton(s) which implement the events to be handled during execution of the application will be unavailable. If a quasi-singleton is available, processing of an event implemented as the quasi-singleton includes the step of reserving the quasi-singleton for use in handling the event. After use thereof, the quasi-singleton is freed for re-use. If the quasi-singleton is unavailable, a new quasi-singleton is created for use in handling the event. Such a result will only occur when a prior handling of an event which used the quasi-singleton was suspended or trapped.